\label{ch:experiment}
In this chapter, design and development of the simulation environment are discussed. Section ~\ref{sec:software} illustrates APIs and software used in the experiment. Section \ref{sec:hardware} presents specification of the hardware used for the experiment. Section ~\ref{sec:simulation} describes the simulation environment along with its limitations.

\section{Software Platform}
\label{sec:software}
In this section, Actor implementation such as Actor Architecture and resource coordination API such as CyberOrgs API are summarized. Because both CyberOrgs API and Actor Architecture are based on Java's concurrency, it was preferred to use a game developed in Java. \emph{JMaPacman} \cite{jmapacman}, an open source multiplayer version of the popular 2-D game \emph{Pacman} is used to illustrate the mechanisms supported by CyberOrgs-MMOG API. \emph{JMaPacman} is developed using \emph{Marauroa} \cite{marauroa}, an open source game engine for multiplayer games. In this section, both \emph{JMaPacman} and \emph{Marauroa} are summarized.

\subsection{Actor Architecture}
\label{subsec:AA}
Actor Architecture \cite{Agha_AC} is Java-based framework that enables a programmer to write actor programs in popular Java syntax. It is actively being developed by the Open Systems Laboratory at the University of Illinois. 

Actor model of programming comprises of concurrent entities called actors. Actors can communicate with each other using asynchronous message-passing. An actor does not share its state with other actors and therefore, the model is free from low-level data races. Actor Architecture provides an execution environment for actors and it supports actor primitives, such as sending and receiving messages, creating new actors, and changing local state. An instance of Actor Architecture run-time system is called an AA platform. 

Actor Architecture uses fair scheduling techniques to schedule messages. It provides pattern-matching services to search and identify an actor that can be located in a local platform or a remote platform.


\subsection{CyberOrgs API}
\label{subsec:cyber}

In Actor Architecture, resource allocation relies on the underlying Java Virtual Machine (JVM). To support resource coordination, Actor Architecture is extended to CyberOrgs \cite{cyber}, which makes the resource control visible to the programmers.

CyberOrgs is developed by adding two key components to the Actor Architecture: CyberOrg Manager and Scheduler Manager. Each instance of a CyberOrgs platform comprises of entities called cyberorgs. A cyberorg encapsulates a set of actors, resources (CPU cycles) and some eCash to buy more resources from another cyberorg. CyberOrg Manager is the central component of each CyberOrgs platform. All resource coordination operations are carried out by the CyberOrg Manager. The results of such operations are sent to Scheduler Manager, which schedules all actors in the platform according to these results. The mechanisms provided by CyberOrgs API includes creation of a new cyberorg entity (isolation), adds mobility to a cyberorg (migration) and merging of two cyberorgs (assimilation). CyberOrgs API can be downloaded from.\footnote{Xinghui Zhao, http://agents.usask.ca/Agents\_Lab/Agents\_Lab\_-\_CyberOrgs.html, access date=7/6/2012}


\subsection{Marauroa Game Engine}
\label{subsec:marauroa}

Marauroa is an open source multiplayer game engine based on Arianne,\footnote{Arianne, http://arianne.sourceforge.net/, access date=7/6/2012} an online gaming framework. It consists of a multiplayer online game engine to develop turn based and real time games, and the various games, which use it. Marauroa provides perception based client-server communication, asynchronous database persistence and handles object management.

Marauroa uses a multithreaded server architecture, TCP socket based communication and a MySQL or H2 based persistence engine. Marauroa, developed in Java provides a flexible game system that allows the developers to extend and modify the game engine. Game scripting can be done using either Java or Python. 

Marauroa is based on a philosophy called Action/Perception, on each turn a perception is sent to all clients connected to a server explaining the surroundings (obstacles, entities, power-ups etc) around them. Clients can request the server to do any action in their names. The result of an action may change the state of the game, which is notified to the clients in the next turn. Marauroa is totally game agnostic, i.e., it makes very little assumptions about the type of game under development, allowing a great freedom in creating games of any genre. Further details are available online \cite{marauroa}.

\subsection{Jmapacman}
\label{subsec:jmapacman}

JMaPacman is a multiplayer remake of the popular classical game \emph{Pacman}. Although JMaPacman is a clone of the old arcade game Pacman, it is built on new game design principles and features. JMaPacman supports multiplayer functionality and allows developers to build customized maps. JMaPacman uses Marauroa game engine to add multiplayer functionality and Java2D to render graphics. Figure ~\ref{fig:jmapacman} shows a screen shot from the game. 


Each JMaPacman instance consists of a game world. This game world comprises of a number of zones. The CyberOrgs-MMOG API assists the zones from the same instance to be distributed over multiple servers by sharing the state of a zone. Dynamic resource coordination is triggered when a particular area of a zone gets over-populated or under-populated. Dynamic resource coordination mechanisms, provided by CyberOrgs-MMOG API allows detection of these load conditions, division of the zones into smaller zones or merging into a larger zone and therefore, distributes the computational load among multiple servers. Each of these zones is encapsulated within a cyberorg entity allowing resource coordination with other cyberorgs.

\begin{figure}
  \centering 
  \includegraphics[scale=0.9]{jmapacman1}
  \caption{Screenshot taken from JMaPacman \cite{jmapacman}}  
  \label{fig:jmapacman}
\end{figure}


\section{System Configuration}
\label{sec:hardware}

Detailed specification of the system used are discussed below:
\\
\\
\textbf{Servers:}\\
A cluster of 4 Apple XServers operated by Mac OSX servers each with 2 x 2.8 GHz quad-core Intel Xeon processors and 8GB of RAM. All of these machines were used as game servers (resources).
\\
\\
\textbf{Client generators:}
\begin{itemize}
\item 1 Mac OSX server with the same configuration as above
\item 1 iMac with Mac OS X v10.5 Leopard,  3.06GHz Intel Core 2 Duo processor and 4GB of RAM
\item 1 MacAir with Mac OSX v 10.6.8 Snow Leopard, 1.8 GHz Intel Core 2 Duo processor and 2 GB or RAM
\end{itemize}

All of these machines were used for creating simulated clients. 


\section{Simulation}
\label{sec:simulation}

There are three types of users who can access the CyberOrgs-MMOG platform - resource owners, game owners and game players. For a particular game, there could be multiple resource owners associated. Same is the case with game players. All of these users connect with the CyberOrgs-MMOG platform through their respective clients. However, this requires a large number of users to properly study the performance of the API. Due to time constraints, instead of going through a user study, a simulator is developed to automate the ownership and resource coordination process (mechanisms supported to game owner and resource owner). 

The simulator has two components - one for automating the resource coordination (integrated with the server) and one to generate simulated clients (as a separate application). Each client is a Java thread that sends random actions to the server and receives perceptions. Each of these threads encapsulates a JMAPacman client. As these clients do not need to render the game on a display device, they are simplified from the original implementation of JMAPacman client. The clients are configured only to send and receive data. Clients are generated with an interval of 0s to 20s which is uniformly distributed. On the other hand, the server-side component collects statistical data from the connected clients, which is used to evaluate the API.

Actions are to navigate the map, which can be any of \emph{up}, \emph{down}, \emph{left} and \emph{right}. Perceptions are basically list of changes in attributes of entities in the player's surrounding. These entities include \emph{walls}, \emph{power-ups}, \emph{enemies} and other \emph{players}. Based on the changes in these surrounding entities a simulated player can choose one of the available actions. If there are multiple available actions that can be executed one of them is chosen in a random fashion. This approach is taken to have the simulated clients behave as close as to the real players. The interval between two consecutive actions is also a random number generated using an uniform random distribution with an interval between 0s to 10s. 
